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REMARKS 

Claims 13-27 are pending. Claims 13, 17 and 21 were amended to recite inherent 
features of the presently claimed invention. Claims 13 and 17 were further amended to improve 
their grammar. 

No new matter was added. Support for the new claim language appears in at least the 
following text portions of the original specification: page 4, lines 26-27; page 7, lines 20-24; 
page 12, lines 16-17; and page 15, lines 17-18. 

Request for Interview Prior to Formal Action on Amendment 

Applicants request an interview prior to formal action on this response. An "Applicant 
Initiated Interview Request Form" accompanies this response. Please contact Applicants' 
undersigned representative to schedule the interview. 

SpecijRcation Objection 

1. Procedural issues 

The objection to the specification is identical to the objection made in a previous Office 
Action dated August 18, 2008, except for the last sentence that appears in the outstanding Office 
Action that offers a suggestion to amend the specification to include specific examples of 
computer readable media. 

Applicants fully responded to the specification objection in the "Response After Final 
Under 37 C.F.R. § 1.1 16" filed on November 26, 2008. See pages 3-4 of this response. 

An Advisory Action mailed on December 11, 2008 includes the following statement by 
the Examiner (underlining added for emphasis) 

In response to the remarks examiner regarding objection, the examiner 
withdraws the object to the specification. 

That is, the Examiner stated that the specification objection was withdrawn . 
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Notwithstanding this statement, the outstanding rejection includes the same specification 
objection. Furthermore, the outstanding rejection does not provide any substantive response to 
the arguments made by Applicants in the November 26, 2008 response as required by 
examination guidelines. Paragraph 15 of the outstanding rejection states that "Applicant's 
arguments with respect to claims 13-27 have been considered but are moot in view of the new 
grounds of rejection." However, as noted above, the specification objection is not a new grounds 
of rejection, and thus a substantive response to Applicants' previous arguments is required since 
an RCE was filed, assuming that the specification objection is being reinstated. The Examiner's 
new statement at the end of the specification objection in the outstanding Office Action is not a 
substantive response to Applicants' arguments. Nor is it a helpftil suggestion because the 
Examiner does not identify where support exists in the original specification for making the 
proposed amendment. 

2. Substantive response to specification objection (repeated from 11/26/08 response) 

The specification was objected for allegedly not providing a proper antecedent basis for 
the limitation "computer-readable medium" in claims 17-20. Applicants respectfully traverse 
this objection because the specification clearly supports this claim limitation and because the 
format of claims 17-20 is explicitly permitted by the USPTO as discussed in MPEP 2106.01, 
Section I. 

Page 15, lines 22-26 of the present specification reads as follows: 

The present invention can be included in an article of manufacture 
(e.g., one or more computer program products) having, for instance, 
computer useable media. The media has embodied therein, for instance, 
computer readable program code means for providing and facilitating the 
mechanisms of the present invention. The article of manufacture can be 
included as part of a computer system or sold separately. 

This text portion clearly supports the claim limitation of a "computer readable medium." 
Furthermore, Appendices A-C and E show source code (i.e., computer-executable instructions) 
that become encoded on the computer-readable medium. 
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The Examiner states that the claimed "computer-readable medium encoded with 
computer-executable instructions" is interpreted as a computer program on a "shelf that is 
waiting to be executed by a computer, and that this should be treated as a claim for a computer 
program which is nonstatutory functional descriptive material. Applicants respectfully traverse 
this characterization of the claimed invention. 

Claims 17-20 are directed to an "article of manufacture" which is a physical thing, such 
as a computer program product. For example, it may a diskette or a memory stick that contains 
software code, that when executed, performs the claimed steps. This is an entirely permissible 
claim format used to capture potential infringement by entities such as software retailers or 
distributers who are not performing the claimed process themselves, and are not selling hardware 
that meets an apparatus claim (e.g., software executing on a computer), but instead are selling 
software via an article of manufacture that performs the claimed process when loaded into a 
computer. 

Furthermore, the Examiner's position is contrary to USPTO policy, as clearly stated in 
MPEP 2106.01, Section I (underlining added for emphasis). 

Data structures not claimed as embodied in computer-readable media are 
descriptive material perse and are not statutory because they are not 
capable of causing functional change in the computer. See, e.g., 
Warmerdam, 33 F.3d at 1361, 31 USPQ2d at 1760 (claim to a data 
structure perse held nonstatutory). Such claimed data structures do not 
define any structural and functional interrelationships between the data 
structure and other claimed aspects of the invention which permit the data 
structure's functionality to be realized. In contrast, a claimed computer- 
readable medium encoded with a data structure defines structural and 
functional interrelationships between the data structure and the computer 
software and hardware components which permit the data structure's 
functionality to be realized, and is thus statutory .. . .When a computer 
program is recited in conjunction with a physical structure, such as a 
computer memory, USPTO personnel should treat the claim as a product 
claim . 


Applicants' claim language is explicitly permitted by the USPTO and cannot be characterized as 
nonstatutory functional descriptive material. 

For at least the reasons set forth above, withdrawal of the specification objection is 
respectfully requested. 
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3. Examiner remarks in rescinded Office Action dated June 1 1 , 2009 

In the paragraph numbered 17 of the rescinded Office Action dated June 11, 2009, the 
Examiner responded to Applicants' arguments in the "Request for Supplementary Action"^ that 
the outstanding rejection includes the same specification objection as previously given and does 
not provide any substantive response to the arguments made by Applicants in the November 26, 
2008 response as required by examination guidelines. 

Applicants have carefiilly reviewed the Examiner's comments in paragraph 17 and note 
that they merely repeat the grounds of the specification objection. Thus, Applicants are unable 
to provide any further amendments or arguments. 

Applicants earnestly wish to advance prosecution of this application and cannot do so 
with respect to this issue based on the outstanding Office Action because the Examiner's position 
is unclear regarding the specification objection. 

Rejection under 35 U.S.C. § 101 

Claims 13-16 and 21-27 were rejected under 35 U.S.C. § 101 for allegedly reciting non- 
statutory subject matter. Applicants respectfully traverse this rejection for at least the reasons set 
forth below. 

In the outstanding Office Action, the Examiner provides the following arguments to 
support the rejection: 

1 . The claims do not meet the "machine-or-transformation test" set forth in In re BilskP. 

2. The steps of "constructing a web page and inserting script into the web page are broad 
enough that the claim could be completely performed mentally, verbally or without a machine 


^ Applicants' undersigned representative was informed by Examiner Flynn in a phone call dated May 12, 2009 that 
this request is being denied and that a communication to this effect will be mailed out. To date, no such 
communication has been received. 
^ A claimed process is patent-eligible under § 101 if: 

(1) it is tied to a particular machine or apparatus, or 

(2) it transforms a particular article into a different state or thing 
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nor is any transformation apparent. For example a web page can be constructed on the piece of 
paper that allows receipt of digital asset." 

Regarding the Examiner's second argument, a web page carmot be constructed on a piece 
of paper because a constructed web page must be rendered, typically by a browser, and code 
written on a piece of paper cannot be rendered in a browser. The very act of constructing a web 
page inherently requires machine elements. While source code of a web page or an artist's 
rendition of a web page could be written out on a piece of paper, rendering that code into 
something that is hvimanly recognizable requires machine elements. 

Appendix A of this paper shows various definitions of a "web page.""^ All of these 
definitions require the presence of the Internet and/or a web browser. For example, the 
definition of a web page as being a "document connected to the World Wide Web and viewable 
by anyone connected to the internet who has a web browser" requires the Internet and a web 
browser. 

Notwithstanding the arguments above, to advance prosecution of the patent application, 
claim 1 3 was amended to recite " electronically constructing a web page from source code " and 
claim 17 was amended to recite " means for electronically constructing a web page from source 
code." The claims now explicitly require machine elements to perform the recited function since 
it would be impossible to electronically construct a web page fi-om source code without machine 
elements. Furthermore, the new language explicitly precludes the claimed invention from being 
constructed on a piece of paper. 

Lastly, claims in an application are to be given their broadest reasonable interpretation 
consistent with the specification, and claim language should be read in light of the specification 
as it would be interpreted by one of ordinary skill in the art. In re Bond, 910 F.2d 831, 833, 15 
USPQ2d 1566, 1567 (Fed. Cir. 1990), attached hereto as Appendix B. Here, the specification 
unequivocally describes machine elements for constructing a web page and inserting script into 
the web page. See, for example, the machine elements in Figures 1 and 16. Nothing even 


Printout of various definitions of "web page" from Google definitions feature, printout date: June 20, 2009, 2 
pages. 
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remotely similar to a paper process is described. Accordingly, an artisan would interpret the 
claimed web page construction process as being machine-implemented. 

Regarding the Examiner's first argument, as discussed above, the claims are clearly tied 
to a particular machine or apparatus. Furthermore, the claims also transform a particular article 
into a different state or thing. Here, a digital asset in a repository becomes incorporated into a 
web page for viewing by a user, thereby transforming the digital asset into a usable piece of 
content which can be rendered in a web page. 

For at least the reasons above, claims 13 and 17 are believed to be statutory. 

Rejection under 35 U.S.C. § 102 

All pending claims were rejected under 35 U.S.C. § 102(b) as allegedly being anticipated 
by Truong^. Applicants respectfully traverse this rejection. 

1. Truong 

Truong discloses a remote system administration method that allows files stored at a 
remote server to be retrieved (and edited, if desired) via a web browser resident on a client 
machine. In this manner, a user does not need to rely upon specialized communication software 
to gain access to such files. Truong operates as follows for retrieving editable files: 

a. An editor input form (also, referred to in Truong as a "network editor input page") is received 
at a forms-enabled and script-enabled web browser through a network from a server in response 
to a request from a client. 

b. The web browser resident on the client then performs the following functions: 

i. Sends a server path input to the server from the web browser. 

ii. Receives a file selection form from the server. The file selection form includes 
filenames identifying files included in a server path defined by the server path input. 

iii. Sends a file selection from the web browser to the server. The file selection identifies 
one of the files. 

^ Page 4 of the Office Action states that claims 13-24 are rejected, but it is presumed that the Examiner meant to 
refer to claims 13-27 because claims 25-27 are discussed on page 5 of the Office Action. 
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iv. Receives a copy of the one of the files from the server. 

V. Edits the copy of the one of the files using the web browser without the use of a plug- 
in to the web browser to produce an updated file. 

vi. Sends the updated file to the server for storage. 
If the retrieved files are marked as being "not editable," then steps v. and vi. are not performed. 

Truong uses embedded script code to facilitate this process. However, the embedded 
script code does not include either of the elements required by the code of the inserted script 
recited in the claimed invention, namely (i) a uniform resource identifier (URI) of a web page for 
use by a remote site in authenticating whether the URI is authorized to receive the content of the 
digital asset, and (ii) a unique identifier of the content of the digital asset. 

Truong's embedded script code is used for a completely different purpose than the 
inserted script of the claimed invention. While Truong discusses URL's and an authentication 
process that verifies logon ID's and passwords, neither of these elements (i) or (ii) are included 
in code of the inserted script. Truong discusses how the embedded script code is used in the 
following text portions (underlining added for emphasis): 


FIG. 2 is a block diagram illustrating client 12 and a remote Internet server 
15 configured as a remote editor system 26. . .A logon script 41 may also 
be stored in client memory 48 and is provided as an embedded script from 
an Internet web page. Logon script 41 is discussed more fully below, 
(column 6, lines 12-24) 

Web browser 32 is also a script-enabled browser which enables it to 
interpret HTML formatted web pages that include embedded script within 
the HTML code. The embedded script is provided to web browser 32 at 
client 12 for enhanced processing at client 12. The embedded script may 
be provided in JAVASCRIPT format or any other scripting language format 
that is provided to a web browser at a client for enhanced processing, 
(column 7, lines 1-8) 

Once a desired web page is retrieved, web browser 32 may receive 
formatting information and embedded script from a file defining the web 
page. The file defining the web page is generally located at a remote 
Internet server, such as remote Internet server 15 as shown in FIG. 2. 
Typically, web browser 32 receives the information in HTML format and 
the embedded script in JAVASCRIPT format so that the web page may be 
interpreted and processed using processor 34 and web browser 32 of 
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client 12 and then graphically displayed at client 12. Often, a web page will 
contain user selectable icons that are preprogrammed with the URL of a 
related web page so that a user may conveniently navigate the Internet by 
selecting these icons, (column 7, lines 20-32) 

Remote editor program 40 is an application program shown loaded into 
server memory 46. Remote editor program 40 is stored in mass storage 
device 44 and is then loaded into server memory 46 when selected by a 
user. This may occur when a user of client 12, while accessing the Internet 
using web browser 32, requests a particular web page that will 
automatically load remote editor program 40 into server memory 46. In 
response, HTML code and any embedded script may be provided to web 
browser 32. For example, logon script 41 . as shown in client memory 48 
with web browser 32, may be provided to client 12 where it is processed 
using web browser 32 and processor 34. (column 8, lines 3-16) 

Remote editor program 40, discussed more fully below in connection with 
FIGS. 3A through 3C, 4, 5, and 6, communicates an editor input form, 
including HTML code and embedded script code , to web browser 32 of 
client 12. In response, client 12 preferably prompts the user for an input 
including a logon ID. a password, and a remote server path using a web 
page, such as that shown in FIGS. 3A through 3C. Remote editor program 
40 may be implemented using a common gateway interface ("CGI") 
program, called a script, that receives the input from web browser 32 of 
client 12, processes the input and executes other programs of remote 
Internet server 15 as necessary, and provides any results to web browser 
32 in HTML format. Appendix A includes some sample code of one such 
implementation of the editor input form of remote editor program 40. 
(column 8, lines 3-16) 

The logon ID, password, and remote server path inputs identify a 
particular user and whether the user has access rights to remote Internet 
server 15. Logon script 41 . provided by remote editor program 40 through 
the editor input form, is stored in client memory 48 and is interpreted by 
web browser 32 to determine whether text has been entered into the logon 
ID input and the password input . Assuming that text has been entered, the 
inputs are communicated back to remote editor program 40 of remote 
Internet server 15 as an input text string. Remote editor program 40 
receives the input text string from the client and parses the input text string 
to identify a server path input. This server path input identifies a particular 
path at remote Internet server 15. Assuming that the user provided a valid 
logon ID and password, as provided through the input text string, remote 
editor program 40 stores the server path input as a variable and generates 
a file selection form. The file selection form includes the text of the file 
names identifying files included in the server path defined by the server 
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path input. Remote Internet server 15, under the control of remote editor 
program 40, communicates the file selection form to the client in HTML 
format, (column 8, lines 17-37) 

FIGS. 3A through 3C depict a flow chart illustrating an exemplary method 
of using remote editor system 26. The method begins at step 100 and 
proceeds to step 102 where a web browser application program is 
executed at a client and the client in turn connects to the server of an 
Internet service provider. At step 104 a user enters the URL of a network 
editor web page stored on a remote Internet server. Next, at step 106 the 
remote Internet server provides the network editor web page to the web 
browser at the client. The network editor web page may also be referred to 
as an editor input form and preferably includes a first part, generally 
provided in HTML format to the web browser or the client, and is used to 
generate an input screen at the client. The network editor web page 
preferably also includes a second part, generally provided in JAVASCRIPT 
format, that is provided to the web browser of the client so that the client 
may perform local processing such as logon script 41 of FIG. 2. The 
network editor web page includes HTML code and JAVASCRIPT code, 
(column 9, lines 1-19) 

The method proceeds next to step 108 where the web browser displays 
the network editor web page at the client. The network editor web page 
provides input fields for a logon ID input, a password input, and a remote 
server path input such as that shown in FIGS. 4. 5. and 6. Then at step 
110 a user provides a logon ID, a password, and a remote server path as 
an input at the web browser of the client, (column 9, lines 20-26) 

At step 112 the web browser, using the embedded logon script provided in 
step 106, performs processing to ensure that the logon ID and password 
fields are not empty. The logon script simply checks to ensure that 
something has been entered in both of these inputs. At decision step 114 it 
determines whether the logon ID input or the password input are empty. If 
so, at step 116, a message is displayed at the web browser of the client 
indicating that a valid logon ID and password must be entered to access 
the system. The method then returns to step 108 where the user has the 
opportunity to enter a valid logon ID and password. Otherwise, the method 
at decision step 114 proceeds to step 118. (column 9, lines 27-39) 

As highlighted above, Truong uses the embedded logon script to create the editor input form 
(network editor input page) and to facilitate entry of data fields into the editor input form. 
However, the editor input form does not contain as part of its code, nor does it facilitate entry of 
(i) a uniform resource identifier (URI) of a web page for use by a remote site in authenticating 
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whether the URI is authorized to receive the content of the digital asset, or (ii) a unique identifier 
of the content of the digital asset. In contrast to Truong, the code of the inserted script in the 
claimed invention requires both of these elements. 

In the outstanding Office Action, the Examiner states that these elements are disclosed in 
column 7, lines 20-33 and column 8, lines 3-16 of Truong. Applicants respectfully traverse the 
relevance of these text portions of Truong to such elements. These text portions read as follows 
(underlining added for emphasis): 


Once a desired web page is retrieved, web browser 32 may receive 
formatting information and embedded script from a file defining the web 
page. The file defining the web page is generally located at a remote 
Internet server, such as remote Internet server 15 as shown in FIG. 2. 
Typically, web browser 32 receives the information in HTML format and 
the embedded script in JAVASCRIPT format so that the web page may be 
interpreted and processed using processor 34 and web browser 32 of 
client 12 and then graphically displayed at client 12. Often, a web page will 
contain user selectable icons that are preprogrammed with the URL of a 
related web page so that a user may conveniently navigate the Internet by 
selecting these icons, (column 7, lines 20-33) 

Remote editor program 40, discussed more fully below in connection with 
FIGS. 3A through 3C, 4, 5, and 6, communicates an editor input form, 
including HTML code and embedded script code, to web browser 32 of 
client 12. In response, client 12 preferably prompts the user for an input 
including a logon ID. a password, and a remote server path using a web 
page, such as that shown in FIGS. 3A through 3C. Remote editor program 
40 may be implemented using a common gateway interface ("CGI") 
program, called a script, that receives the input from web browser 32 of 
client 12, processes the input and executes other programs of remote 
Internet server 15 as necessary, and provides any results to web browser 
32 in HTML format. Appendix A includes some sample code of one such 
implementation of the editor input form of remote editor program 40. 
(column 8, lines 3-16) 

The URL discussed in column 7, line 30 is not part of the embedded script code 
described in Truong. This text portion merely states the well-known fact that an icon can have a 
URL embedded therein. Furthermore, the conventional icon-related URL does not require 
authentication to determine if the user can receive the web page or content associated with the 
icon-related URL. 
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Column 7, lines 20-29 of Truong merely describes how a web page receives information 
in HTML, and also describes that the web page can include embedded script, such as Javascript. 
Nothing in this text portion relates to (i) a uniform resource identifier (URI) of a web page for 
use by a remote site in authenticating whether the URI is authorized to receive the content of the 
digital asset, or (ii) a unique identifier of the content of the digital asset. 

Column 8, lines 3-16 of Truong describes two types of script, namely, (i) embedded script 
code in the browser (logon script 41 that checks that something has been entered into logon ID 
and password fields before sending a request to a server), and (ii) a CGI program that executes at 
the server, receives form data from the browser, generates file name text for each server file 
stored in the directory identified by the server path input variable, and returns the file names to 
the client machine for display. A remote server path is not a unique identifier of content of a 
digital asset. A remote server path is merely a location or directory where content may reside. 
For example. Fig. 4 of Truong shows a remote server path that includes eight files. 

Furthermore, the authentication that is performed in Truong at the server (i.e., did the 
user provide a valid logon ID and password?) merely checks that the user is entitled to receive 
the file names and their content. This has nothing to do with using a uniform resource identifier 
(URI) of a web paRe in authenticating whether the URI is authorized to receive the content of a 
digital asset. 

Neither of the scripts described in column 8, lines 3-16 of Truong include any code that 
relates to (i) a uniform resource identifier (URI) of a web page for use by a remote site in 
authenticating whether the URI is authorized to receive the content of the digital asset, or (ii) a 
unique identifier of the content of the digital asset. Nor do any other portions of Truong disclose 
or suggest such code. 

2. Patentable differences between Truong and claimed invention 

Except for the fact that Truong discloses that script may be inserted into a web page, 
which Applicants are not claiming to have invented, Truong has nothing whatsoever to do with 
the claimed invention. The following table provides a snapshot view of the deficiencies in 
Truong: 
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Claim language 

Portions of Truong 
highlighted by 
Examiner 

Applicants' rebuttal comments 




13. A method of 
constructing a web page 
that allows for receipt of 
digital assets, the 
method comprising: 

Examiner asserts that 
Truong provides this 
function. 

Truong does not disclose constructing a web 
page, even under Truong's own definition of 
a web page, as described in column 1 , lines 
42-50. For example, the output displays 
shown in Figs. 4 and 5 do not show a web 
page having a unique URL. At best. Fig. 4 
shows a listing of editable files, and Fig. 5 
shows coding that mav describe a web page, 
but nothing in the coding allows for receipt 
of digital assets. 




(a) electronically 
constructing a web page 
from source code; and 

Figs. 4 and 5 

Truong does not disclose constructing a web 
page, even under Truong's own definition of 
a web page, as described in colirain 1 , lines 
42-50. For example, the output displays 
shovm in Figs. 4 and 5 do not show a web 
page having a unique URL. At best. Fig. 4 
shows a listing of editable files, and Fig. 5 
shows coding that mav describe a web page. 




(b) inserting script 
associated with at least 
one digital asset that is 
desired to be part of a 
fully rendered web page 
into the web page. 

column 2, lines 1 7-3 1 

At best, this background text portion of 
Truong merely discloses that script may be 
inserted into a web page. (As noted above. 
Applicants are not claiming to have invented 
constructing a web page that includes 
script.). Nothing in this text portion 
discusses that Javascript is "associated with 
at least one digital asset that is desired to be 
part of a fullv rendered web page." 
Furthermore, Truong's invention is not even 
using Javascript for this purpose. Instead, 
Truong merely uses Javascript for a logon 
script 41 to check that something has been 
entered into logon ID and password fields 
before sending a request to a server. 




the inserted script 
including code to 
request the content of 
the digital asset 

server file, column 10, 
lines 5-14 

Column 10, lines 5-14 merely describes the 
process of generating file name text for each 
server file stored in the directory identified 
by the server path input variable, as shown 
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in Fig. 4. This process simply generates a 
directory listing of whatever files happen to 
be located at the path, regardless of their 
content characteristics or ability to edit or 
view them. Stated another way, the request 
that occurs in Truong does specifically ask 
for "digital assets." In fact, there may be no 
digital assets at all located at the path. The 
request in Truong will merely return 
whatever files are located at the path. 

Thus, to the extent that the logon script 41 is 
used in a process that requests files from a 
server, there is no code in the logon script 41 
that requests content of a digital asset. 




from a remote site when 
the code is executed by a 
browser. 

column 8, lines 3-16 

Column 8, lines 3-9 merely describes logon 
script 41 that is used to check that something 
has been entered into logon ID and password 
fields before sending a request to the server. 
As discussed immediately above, this 
request is not a request for content of a 
digital asset. 

Column 8, lines 9-16 discusses script (CGI 
program) that receives form data from the 
browser and is executed at the server, not at 
the browser, so this portion of Truong is not 
relevant. Furthermore, the server-executed 
script also does not request the content of a 
digital asset. Instead, it generates file name 
text for each server file stored in the 
directory identified by the server path input 
variable and returns the file names to the 
client machine for display. 




the code including: 
(i) a uniform resource 
identifier (URI) of the 
web page for use by the 
remote site in 
authenticating whether 
the URI is authorized to 
receive the content of 
the digital asset, and 

column 7, lines 20-33 
and column 8, lines 
3-16 

As discussed above, the URL discussed in 
column 7, line 30 is not part of the 
embedded script code described in Truong. 
This text portion merely states the well- 
known fact that an icon can have a URL 
embedded therein. Furthermore, the icon- 
related URL does not require authentication 
to determine if the user can receive the web 
page or content associated with the icon- 
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(ii) a unique identifier of 
the content of the digital 


related URL. 

Column 7, lines 20-29 merely describes how 
a web page receives information in HTML, 
and also describes that the web page can 
include embedded script, such as Javascript. 
Nothing in this text portion relates to (i) a 
uniform resource identifier (URI) of a web 
page for use by a remote site in 
authenticating whether the URI is authorized 
to receive the content of the digital asset, or 
(ii) a unique identifier of the content of the 
digital asset. 

Column 8, lines 3-16 of Truong describes 
two types of script, namely, (i) embedded 
script code in the browser (logon script 41 
that checks that something has been entered 
into logon ID and password fields before 
sending a request to a server), and (ii) a CGI 
program that executes at the server, receives 
form data from the browser, generates file 
name text for each server file stored in the 
directory identified by the server path input 
variable, and returns the file names to the 
client machine for display. A remote server 
path is not a unique identifier of content of a 
digital asset. A remote server path is merely 
a location or directorv where content may 
reside. For example, Fig. 4 of Truong shows 
a remote server path that includes eight files. 

Furthermore, the authentication that is 
performed in Truong at the server (i.e., did 
the user provide a valid logon ID and 
password?) merely checks that the user is 
entitled to receive the file names and their 
content. This has nothing to do with using a 
uniform resource identifier (URI) of a web 
page in authenticating whether the URI is 
authorized to receive the content of a digital 
asset. 

Neither of the scripts described in column 8, 
lines 3-16 of Truong include any code that 


Application No. 09/923,923 

Reply to Office Action dated February 3, 2009 




relates to (i) a uniform resource identifier 
(URI) of a web page for use by a remote site 
in authenticating whether the URI is 
authorized to receive the content of the 
digital asset, or (ii) a unique identifier of the 
content of the digital asset. Nor do any 
other portions of Truong disclose or suggest 
such code. 





3. Patentability of independent claims 13,17 and 21 over Truong 

Claim 13 reads as follows (underlining added for emphasis): 


1 3. A method of constructing a web page that allows for receipt of digital 
assets , the method comprising: 

(a) electronically constructing a web page from source code ; and 

(b) inserting script associated with at least one digital asset that is desired 
to be part of a fully rendered web page into the web page , the inserted 
script including code to reguest the content of the digital asset from a 
remote site when the code is executed by a browser , the code including: 

(i) a uniform resource identifier (URI) of the web page for use by the 
remote site in authenticating whether the URI is authorized to receiye the 
content of the digital asset , and 

(ii) a unique identifier of the content of the digital asset . 

As discussed above, and as summarized in the table, Truong does not disclose or suggest any of 
the above-highlighted features in claim 13. Accordingly, claim 13 is believed to be patentable 
over Truong. 

Claims 17 and 21 are also believed to be patentable over Truong for the same reasons as 
applied to claim 13. 

A claim is anticipated only if each and every element as set forth in the claim is found, 
either expressly or inherently described, in a single prior art reference. MPEP 2131. Here, none 
of the claimed elements are disclosed in Truong. Accordingly, withdrawal of the prior art 
rejection is respectfully requested. 


-19- 


Application No. 09/923,923 

Reply to Office Action dated February 3, 2009 


4. Patentability of dependent claims 

The dependent claims are believed to be patentable over the applied references for at least 
the reason that they are dependent upon allowable base claims and because they recite additional 
patentable elements and steps. 


Conclusion 


Insofar as the Examiner's rejections were fully addressed, the instant application is in 
condition for allowance. Issuance of a Notice of Allowability of all pending claims is therefore 
earnestly solicited. 


Respectfiilly submitted, 
RICHARD D. MARTIN et al. 

CLARK A. JABLOM \ 
Registration No. 35,039 

PANITCH SCHWARZE BELISARIO & NADEL LLP 
One Commerce Square 
2005 Market Street - Suite 2200 
Philadelphia, PA 19103 
Telephone: (215)965-1330 
Direct Dial: (215) 965-1293 
Facsimile: (215)965-1331 
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Google f 


Idefine: web page 



Related phrases: static web page dynannic web page web page design electric guitar web pa ge ltd web pag e 
l aser focus w o rld web pag e classic mask web pag e cord web page push web pa ge technologies 

Definitions of web page on the Web: 

• a document connected to the World Wide Web and viewable by anyone connected to the internet who has a 
web browser 

wordnet.princeton.edu/perl/webwn 

• A web page or webpage is a resource of information that is suitable for the World Wide Web and can be 
accessed through a web browser. This information is usually in HTML or XHTML format, and may provide 
navigation to other web pages via hypertext links. 

en. wik ipedi a .o r g/ w i ki/W eb page 

• Alternative spelling of web page 
en.wiktionary.org/wiki/web-page 

• a single page in a website, together with any referenced images or scripts etc; often hyperlinked to others 
en.wiktionarv.org/wiki/w eb page 

• A document written in HTML that can be accessed on the Internet. Every Web page has a unique address called 
a URL. Web pages can contain text, graphics, and hyperlinks to other web pages and files. 
www.b u gclub .org /glossarv.html 

• A document designed for viewing in a web browser. Typically written in HTML. A web site is made of one or 
more web pages. 

www.odove.com/Websitelnfo/Glossary/tabid/209/language/en-US/Default.aspx 

• A location on the World Wide Web, identified by a URL, which contains a block of data. 
www.lavc.cc.ca.us/virtualvalley/onlinedefinitions.htm 

• A document on the World Wide Web. Every Web page is identified by a unique URL (Uniform Resource 
Locator). 

www, maineweblx. com/g lossary 

• This is a single document on the internet. 
www.broadband-guide.org.uk/jargon-buster.htmi 

• A 'page' of information available to anyone via the internet 
www.nakedit.com.au/Content.aspx 

• An HTML document that is accessible on the Web. 
www-personal.umich.edu/~zoe/Glossary.html 

• A hypermedia document as viewed through a World Wide Web browser 
www.martech-intl.com/ be st 2 /g lossary.htm 


a single document on a Web site 

wvw.classzone.com/books/research_quide/page build. cfm 


• A document containing text and grapliics that can be accessed through a web browser on the internet. 
www.100best.com/articles4 0 .h t ml 


• A computer document available over the World Wide Web. A Web page is a given file stored on a Web server, 
and written in HTML. It is transferred from the server to the client using HTTP. 
t eladesign.com/ma-thesis/glossary.html 

Find definitions of web page in: Chinese (Simplified) Chinese (Traditional) Dutch English German Italian 
Portuguese Russian Spanish all languages 


[define: web page Search | 

Language Tools - Search Help - Dissatisfied? Help us improve - Try Google Experimental 


Google Home - Advertising Programs - Business Solutions - Privacy - About Google 
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